Method and framework for integrating a plurality of network policies

ABSTRACT

A method and system is disclosed for managing and implementing a plurality of network policies in a network device. Each of the plurality of policies are defined by one or more filters. The filters are installed in a policy engine. A layer identifies the network policy to be applied to a packet by sending a request to the policy engine. The policy engine then returns the policy to the requesting layer. The method and system may be used to implement a programmable, host-based, distributed, authenticating firewall that enables security and other policies to be applied at several protocol layers.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a division of U.S. application Ser. No. 10/456,093,filed Jun. 6, 2003 entitled METHOD AND FRAMEWORK FOR INTEGRATING APLURALITY OF NETWORK POLICIES, which application is incorporated hereinby reference in its entirety.

The present application contains subject matter related to that ofpatent applications “Multi-Layer Based Method for Implementing NetworkFirewalls,” Ser. No. 10/456,770; “Multi-Layered Firewall ArchitectureImplemented in a Network Device,” Ser. No. 10/456,766, and “Method forManaging Network Filter Based Policy,” Ser. No. 10/456,433, filed on thesame day as the parent application, the disclosures of which are herebyexpressly incorporated by reference.

TECHNICAL FIELD

This invention generally relates to computer systems and to networksecurity. More particularly, this invention relates to a method ofintegrating a plurality of network policies into a single frameworkwithin a network device.

BACKGROUND OF THE INVENTION

Network protocols are designed to facilitate communication betweennetwork devices through an open exchange of data. While the openexchange of data greatly enhances the use of network devices toaccomplish tasks, it also creates problems because network protocols arenot designed for, and generally do not provide, network security.Computers coupled to both public and private networks, such as LocalArea Networks (LANs), Wide Area Networks (WANs), intranets, and theInternet are susceptible to malicious attacks perpetrated by othernetwork devices coupled either directly or indirectly to the network.Such malicious attacks include theft of data, Denial of Service (DOS)attacks, the proliferation of computer viruses, and the like.

Various methods have been developed to protect network devices againstmalicious attacks usually through implementation of one or more networkpolicies. One network policy is a security policy such as provided forby the Internet Protocol Security (IPSec) Suite. The IPSec suiteprovides protocols such as Encapsulating Security Protocol (ESP),Authentication Header (AH), and Internet Key Exchange and Management(IKE) protocol. The ESP protocol, documented in Internet EngineeringTask Force (IETF) Request for Comments (RFC) 2406, is an authenticatingand encrypting protocol that uses cryptographic mechanisms to provideintegrity, source authentication, and confidentiality of data. The AHprotocol, documented in IETF RFC 2402, is an authentication protocolthat uses a hash signature in the packet header to validate theintegrity of the packet data and authenticity of the sender.

The IKE protocol, documented in IETF RFC 2409, provides a method fornetwork devices to negotiate security settings used with the AH and ESPformats. The negotiated security settings form a data structure called asecurity association (SA). The SA defines parameters such as theauthentication algorithm, encryption algorithm, keys, and the lifetimeof keys, used by ESP or AH to protect the contents of the IP packet.Because ESP and AH require an established SA, an IKE negotiation isexecuted before the ESP or AH protocols are used to transmit data.

A network device identifies packets that are subject to IPSec, e.g. IKE,AH, or ESP, processing and the manner that such packets should be IPSecprocessed based on a security policy maintained in a Security PolicyDatabase (SPD). The security policy is a set of rules assigned to thenetwork device that defines how to use IPSec. The security policyincludes filter lists, authentication methods and other information. Theproper security policy to be applied to a packet is usually determinedbased upon the packet's source and destination IP address, source anddestination ports, and protocol type.

Another network policy used to protect against malicious attacks is afirewall policy. The firewall policy is implemented by one or morefilters. Each filter includes filter parameters and associated policy tobe applied to packets that match the filter parameters. The filterparameters include information such as hardware addresses, e.g. MediaAccess Control (MAC) addresses, network addresses, e.g., IP addresses,protocol type, e.g. Transport Control Protocol (TCP), port numbers, andthe like. The firewall policy in the filter identifies how packets withparameters that match the filter parameters should be treated. As aspecific example, the filter includes as its parameters a UniformResource Locator (URL) address, e.g. “http://www.foo.com.” The filterpolicy indicates that packets with that URL address should be dropped.Whenever the network device examines a packet and through thatexamination identifies the URL address “http://www.foo.com” as embeddedin the packet, the network device drops the packet thereby preventing itfrom traversing the network.

Network devices also use non-security related policies to control theflow of network traffic. As one example, network devices implementQuality of Service (QOS) based policy. QOS addresses the fact thattransmission rates, error rates, and other characteristics can bemeasured, improved, and to some extent guaranteed in advance. Packetscan be expedited based on policy and reservation criteria. QOS is used,for example, to allocate network bandwidth for improved communicationsbetween network devices.

It is not uncommon for multiple policies, e.g. security policy, firewallpolicy, QOS policy, and the like to be implemented in a network device.These policies may conflict, i.e. identify contradictory actions to takeon the same packet. Implementing multiple network policies in a networkdevice also makes it difficult to diagnose packet transmission problems.For example, if packets are not being properly transmitted or received,it is difficult to identify which of the network policies is interferingwith the packets.

SUMMARY OF THE INVENTION

The invention is directed to a method and framework for implementing aplurality of network policies in a network device. The plurality ofnetwork polices are defined by a set of filters installed in a policyengine. Each filter includes a set of filter conditions, an action, anda policy context. The filter conditions include parameters that allowthe policy engine to identify one or more filters that match a packet.The action and policy context identify the network policies that applyto packets matching the filter conditions.

A requesting layer sends a request to the policy engine with a set ofparameters associated with the packet. The policy engine identifies oneor more matching fibers for the packet by comparing the parametersassociated with the packet to the filter conditions. The network policyis then identified from the policy context and action in the matchingfilters. After the network policy is identified, it is executed by thenetwork device.

In an embodiment of the invention, one of the plurality of networkpolicies is a firewall policy implemented by including as the action inthe set of filters, permit or block thereby identifying whether packetsmatching the filter conditions should be permitted to traverse layers ina network stack or conversely blocked from further network traversal.

In an embodiment of the invention, one of the plurality of policies is asecurity policy including as the policy context data identifying thesecurity policy to be applied to packets matching the filter conditions.

In an embodiment of the invention, one of the plurality of policies is aquality of service policy including as the policy context dataidentifying communication settings to be applied to packets matching thefilter conditions.

The method and framework of the present invention may be used toimplement a programmable, host-based, distributed authenticatingfirewall that enables security and other policies to be applied atseveral protocol layers. Additional features and advantages of theinvention will be made apparent from the following detailed descriptionof illustrative embodiments, which proceeds with reference to theaccompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

While the appended claims set forth the features of the presentinvention with particularity, the invention, together with its objectsand advantages, may be best understood from the following detaileddescription taken in conjunction with the accompanying drawings ofwhich:

FIG. 1 is a block diagram generally illustrating an exemplary computersystem on which the present invention resides;

FIG. 2 is a block diagram of an exemplary network environment whereinthe present invention may be used;

FIG. 3 is a block diagram of a system architecture used to implement andmanage a plurality of network policies;

FIG. 4 illustrates an exemplary data structure for a policy filter;

FIG. 5 illustrates an exemplary data structure for packet context;

FIG. 6 illustrates exemplary application programming interfaces usedwith the present invention;

FIG. 7 illustrates an exemplary application programming interface usedwith the present invention;

FIG. 8 is a block diagram illustrating a requesting layer obtainingpolicy for data;

FIG. 9 is a flow chart illustrating a method used by a requesting layerto implement network policy;

FIG. 10 is a flow chart illustrating a method used by a policy engine toidentify network policy for data; and

FIG. 11 is a flow chart illustrating a method used to add new policyfilters into a policy engine.

DETAILED DESCRIPTION OF THE INVENTION

A method and framework of implementing and managing a plurality offilter based network policies in a network device is described. Typicalfilter based network policies include security policy, firewall policy,and QOS policy. The plurality of filter based network policies arestored in a filter policy engine.

The filter based policies are implemented in a framework that includes auser policy engine and a kernel policy engine. The framework alsoincludes kernel layers and user layers. The kernel policy engine, kernellayers, and one or more callouts execute within the kernel mode of anoperating system. The kernel layers include an application layer, atransport layer, a network layer, and link layer forming a networkstack. The user policy engine and user mode layers execute in anoperating system user mode, along with one or more policy providers. Anexemplary user layer is a keying module layer used to identify securitypolicy. Alternatively, the method and framework of the present inventionexecutes within a single operating system mode, or within one or moreprogram modules or applications executing outside of the operatingsystem.

The user layers and kernel layers each form a requesting layer thatreceive a packet and corresponding packet context data from a previouslayer or system process. The requesting layer sends a request to thekernel policy engine or the user policy engine via an applicationprogramming interface (API). The request includes information such asthe packet received by the requesting layer, the packet context, and aset of layer parameters associated with the requesting layer. The policyengine processes the request and returns an action and policy context.The layer then implements the network policy according to the action andpolicy context.

The plurality of network policies are defined by a set of installedfilters. Each of the set of installed filters includes a set of filterconditions, an action, and policy context. The action is used to returnfirewall policy such as permit or block. The policy context includesother policy such as security or QOS policy. The kernel or user policyengine processes the request sent from the requesting layer byidentifying one or more matching filters. The matching filters havefilter conditions that match the layer parameters and packet context.

The policy providers are used to create network policy and derive thepolicy from any suitable source such as volatile or non-volatile memoryor through a graphical user interface. The policy is a source ofinformation for rendering a new filter, including the set of filterconditions, action, and policy context. The user policy engine adds thenew filter to the set of installed filters in the user policy engine orkernel policy engine.

Turning to the drawings, wherein like reference numerals refer to likeelements, the invention is illustrated as being implemented in asuitable computing environment. Although not required, the inventionwill be described in the general context of computer-executableinstructions, such as program modules, being executed by a personalcomputer. Generally, program modules include routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. The invention may also bepracticed in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

FIG. 1 illustrates an example of a suitable computing system environment100 on which the invention may be implemented. The computing systemenvironment 100 is only one example of a suitable computing environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing environment100 be interpreted as having any dependency or requirement relating toany one or combination of components illustrated in the exemplaryoperating environment 100.

The invention is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

With reference to FIG. 1, an exemplary system for implementing theinvention includes a general purpose computing device in the form of acomputer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Associate (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus also known as Mezzanine bus.

Computer 110 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 110 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of the any of the aboveshould also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 1 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 1, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 1, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers hereto illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as akeyboard 162 and pointing device 161, commonly referred to as a mouse,trackball or touch pad. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit120 through a user input interface 160 that is coupled to the systembus, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB). A monitor191 or other type of display device is also connected to the system bus121 via an interface, such as a video interface 190. In addition to themonitor, computers may also include other peripheral output devices suchas speakers 197 and printer 196, which may be connected through a outputperipheral interface 195.

The computer 110 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be another personal computer, a server,a router, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the personal computer 110, although only a memory storage device 181has been illustrated in FIG. 1. The logical connections depicted in FIG.1 include a local area network (LAN) 171 and a wide area network (WAN)173, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the personal computer 110 isconnected to the LAN 171 through a network interface or adapter 170.When used in a WAN networking environment, the computer 110 typicallyincludes a modem 172 or other means for establishing communications overthe WAN 173, such as the Internet. The modem 172, which may be internalor external, may be connected to the system bus 121 via the user inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the personal computer110, or portions thereof, may be stored in the remote memory storagedevice. By way of example, and not limitation, FIG. 1 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

In the description that follows, the invention will be described withreference to acts and symbolic representations of operations that areperformed by one or more computer, unless indicated otherwise. As such,it will be understood that such acts and operations, which are at timesreferred to as being computer-executed, include the manipulation by theprocessing unit of the computer of electrical signals representing datain a structured form. This manipulation transforms the data or maintainsit at locations in the memory system of the computer, which reconfiguresor otherwise alters the operation of the computer in a manner wellunderstood by those skilled in the art. The data structures where datais maintained are physical locations of the memory that have particularproperties defined by the format of the data. However, while theinvention is being described in the foregoing context, it is not meantto be limiting as those of skill in the art will appreciate that variousof the acts and operation described hereinafter may also be implementedin hardware.

A network environment wherein the method of implementing and managing aplurality of filter based network policies according to the presentinvention will now be described with reference to FIG. 2. The network isexemplary in nature as the method of the present invention isimplemented in any network device that is coupled to any networkconfiguration. The network environment includes a private network 200and a public network 202. The private network 200 and public network 202are any suitable type such as Local Area Networks (LANs), Wide AreaNetworks (WANs), intranets, the Internet, or any combination thereof.

The network environment includes a plurality of network devices 204,206, 208, 210 and 212. Network devices 204, 206 are coupled to theprivate network 200. Network devices 210, 212 are coupled to the publicnetwork 202. The network device 208 is coupled to, and provides aninterface between, both the private network 200 and the public network202. The network devices are coupled to the public and private networksusing any suitable technology such as Ethernet, 1394, or 802.11(b). Thenetwork devices are further implemented as any suitable computingdevices such as personal computers, servers, handheld devices, printers,switches, routers, bridges, repeaters or the like.

The network device 208 includes a filter management module 214 and oneor more filters 216. The management module 214 is a program module or aset of program modules, implemented according to the present invention.The management module 214 examines network packets exchanged between thenetwork devices 204, 206, 208 coupled to the private network 200 and thenetwork devices 210, 212 coupled to the public network 202. In anembodiment of the invention, the management module 214 also examineslocally destined network packets sent from, and destined to, networkdevices within the private network 200.

The management module 214 controls network traffic exchanged between theprivate network 200 and the public network 202. Alternatively, themanagement module 214 is implemented in, and controls network trafficfor, a single network device such as illustrated in the network device210. The management module is also capable of being implemented as acentrally administered set of hosts and/or edge network devices

The filters 216 are implemented as part of the management module 214.Alternatively, the filters 216 are implemented as part of a separatedata structure accessible by the management module 214. Each filter 216includes a set of filter conditions, an action, and policy context. Thefilter conditions are used to identify data that is subject to networkpolicy and include information such as interface numbers, hardwareaddresses, network addresses, protocol type, port numbers, and payloaddata. The action is used to implement firewall policy and indicates howthe network device implementing the management module should treatpackets that match the filter conditions. Typical actions includepermit, i.e. allow the packet to continue network traversal, and block,i.e. preclude further network traversal by dropping packet. The policycontext is used to store information identifying other network policies,such as security and QOS policies, which are likewise to be applied topackets matching the filter conditions.

As used herein, the term network packet or packet refers to data. Thedata may be formatted according to a network protocol such as IP, TCP,HTTP or may include a basic data stream. By comparing packetinformation, referred to herein as packet parameters, to the filterconditions, the management module identifies one or more matchingfilters. A matching filter results when the filter conditions match thepacket parameters. The packet parameters include information that isderived from the packets and includes packet context information andlayer parameters. When the management module identifies a matchingfilter, the one or more actions and/or policy context associated withthe filter conditions are executed.

FIG. 3 shows an exemplary architecture of the management module 214. Thearchitecture of the management module 214 allows packets to be subjectto filters at both kernel and user layers. The architecture providescentral management capabilities that allow filters to be added anddeleted and for filter conflicts to be identified and resolved. Themanagement module 214 is extensible in that kernel or user mode layersare added and deleted as needed and is expanded to include specializedfunctionality via callout modules. The present invention is particularlysuitable for implementing and managing filters used with a plurality ofnetwork policies such as firewalls, Quality of Service (QOS), InternetProtocol Security (IPSec) suite, as well as other encrypting,authenticating, and key management security protocols.

The management module 214 includes a user mode process 250 and a kernelmode process 252. The user mode process 250 and kernel mode process 252execute as part of an operating system in a network device. Thoseskilled in the art will appreciate that the user mode process 250 andthe kernel mode process 252 of the operating system include additionalcomponents that for simplicity are not shown. Alternatively, themanagement module 214 is executed in whole or in part outside of theoperating system as one or more program modules or application programs.

The kernel mode process 252 includes kernel layers 254, a kernel policyengine 256, and optional callouts 258. The kernel mode process 252implements an established network policy by identifying matching filtersfor network packets, processing packets according to known protocols,and executing other actions on the packet as designated by matchingfilters.

In an embodiment of the invention, the kernel layers 254 form a networkstack. The network stack comprises a plurality of layers including adata stream layer 268, a transport layer 270, a network layer 272, and alink layer 274. The management module is extensible and additionallayers are dynamically added and deleted as needed. An example of anadded layer includes file access layer 276, implemented according to aServer Message Block (SMB) protocol. The kernel mode process 252 ispreferably configured to implement firewall policy to be applied topackets traversing the kernel layers 254.

The kernel policy engine 256 includes a layer API 280, a set ofinstalled filters 282, and a callout API 284. The kernel policy engine256 performs various functions according to the method of the presentinvention including (1) maintaining the set of installed filters 282defining network policies, e.g., security, QOS, firewall policy and thelike, (2) receiving requests from the kernel layers 254, (3) identifyingone or more matching filters based on the request, and (4) instructingthe layer of any action to take on the packet based on the matchingfilters and network policy defined therein.

The user policy engine 260 includes a filter module 294. The filtermodule 294 is an instance of the kernel policy engine 256 in the usermode 250. The instance of the filter module 294 in the user policyengine 260 permits the user policy engine 260 to replicate the servicesof the kernel policy engine 256 for one or more user layers 282. Theuser layers 282 are added in the same way that kernel mode layers arecreated. Because the filter module 294 is the user mode instance of thekernel policy engine 256, it will be understood that any functionalitydescribed herein for the kernel policy engine also applies to the filtermodule 294. For example, additional user mode layers are added ordeleted from the system architecture and callouts may be created therebyproviding added functionality to the user mode layers. Filters 278defining network policy are added into the filter module 294, and usermode layers 282 can identify policy for packets or data matchingdesignated parameters by sending a request to the user policy engine260. While the user layers 282 are shown executing in the operatingsystem user mode, the user layers may also be distributed in othersystem processes.

The set of installed filters 278, 282 are used to implement one or morenetwork policies. Each filter includes a set of filter conditions, anaction, and policy context. As described with reference to FIG. 2, thefilter conditions identify the packets that are subject to the filterpolicy as defined by the action and policy context. The actionsspecified in the set of installed filters 282 include permit and block.The policy context is any suitable data structure used to store knownpolicy parameters for policies such as security and QOS. An exemplaryform of the filters is described with reference to FIG. 4.

The layer API 280 provides an interface between the kernel layers andthe kernel policy engine. Through the layer API 280, the requestinglayer requests the kernel policy engine to identify network policy to beapplied to a packet.

The callouts 258 are used to implement added functionality such asparental controls, intrusion detection, and the like. A callout isexecuted when the kernel or user policy engine 256 identifies a matchingfilter for the packet that includes, as the associated action, a calloutto one of the callout modules. Additional callouts, like layers, areadded as needed thereby providing an extensible architecture. A specificimplementation of the callout API 284 is described with reference toFIG. 6.

The user mode process 250 includes the user policy engine 260 and one ormore policy providers 262 identified as “PP1,” “PP2,” and “PP3.” Thepolicy providers 262 are processes that add network policy, i.e.installed filters 278, 282, into the management module 214. Any processis used to accomplish this task. An example is a legacy IPSec policyservice (LIPS). The legacy IPSec policy service adds filters definingnetwork traffic that is supposed to use Internet Protocol Security(IPSec) such as Encapsulating Security Protocol (ESP) and AuthenticationHeader Protocol (AH). As a specific example, the legacy IPSec policyservice adds a firewall policy indicating that all unsolicited inboundpackets must be encrypted according to the ESP protocol. The policyfurther provides that any unsolicited inbound packet in clear text, i.e.an unencrypted packet, should be blocked. The policy providers 262obtain the policy from any suitable source such as data in volatile ornonvolatile memory, or a Graphical User Interface (GUI) that permits anadministrator or system users to directly enter policy. The user policyengine 260 converts the policy into a new filter, i.e. defines thepolicy in terms of filter conditions and associated actions, and addsthe new filter into the set of installed filters 278, 282.

The management module 214 further includes a filter engine API 266 thatforms an interface between the user policy engine 260 and the kernelpolicy engine 256. The engine API 266 provides a mechanism for the userpolicy engine 260 to add new filters into the set of installed filters282, and to examine installed filters 282 matching selected criteria fordiagnostic purpose. A management API 290, accessible by policy providers262, also provides a mechanism to add and remove filters from thearchitecture.

Each user and kernel layer is capable of receiving a packet from aprevious layer, module or system process. Each user or kernel layer alsomaintains packet context, passes the packet context to a next layer orsystem process, issues a classification request to the kernel or userpolicy engine, and takes action on the packet according to the one ormore network policies.

The packet context is a data structure that follows the packet. Eachlayer maintains the context by adding into the context data structure aset of parameters that the layer is designed to process or that may bederived from the packet. An exemplary data structure used for the packetcontext is described with reference to FIG. 5.

The classification request is a call by a layer requesting that anyfilters that match the packet be identified and any action, e.g. permitor block, and/or associated policy context be returned to the layer. Thelayer issuing the classification request is referred to herein as arequesting layer. Each layer also takes the action on the packet that isreturned by the kernel or user policy engine.

The management module 214 also includes a keying module layer 296. Thekeying module layer is used to lookup network policies used with keyingprotocols such as the Internet Key Exchange and Management (IKE)protocol implemented as part of a security protocol such as IPSec. Akeying module API 288 provides an interface between the user policyengine 260 and the keying module layer. Filters can be added to thefilter module 294 through the user policy engine 260 defining whichpackets are subject to a given set of security parameters. The keyingmodule API provides a mechanism for other processes to invoke theservices of the keying module layer to identify matching installedfilters that include policy context identifying the policy to beapplied.

Referring to FIG. 4, the set of installed filters 282, which may beinstalled into filter module 294 or kernel policy provider 256, will nowbe described. Each filter 310 has a plurality of fields including afilter Id 312, a weight 314, one or more Actions 316, a policy context317 and a set of filter conditions 318. The filter Id 312 provides aunique identification to the filter.

The weight field 314 includes a value that identifies priority of thefilter 310. The higher the value in the weight field 314, the higher thepriority of the filter. The filter priority determines the order wherebymatching filters are applied to the packet by the kernel policy engine256 or user policy engine. Alternatively, the filter 310 is manuallyordered and the weight field 314 is optionally excluded.

The set of filter conditions 318 determine whether a packet matches thefilter 310. Each filter condition 318 includes a type 320, data 322, anda layer Id:field Id 324. The number of filter conditions 318 isdynamically configurable, such that a filter can include any number offilter conditions 318, and filter conditions 318 can be added or deletedas the need arises.

The type 320 defines the length and number of variables included in thecorresponding data 322. The architecture provides for predefined knownvariable types such as Byte, Short, Long, 8 Bytes, String, InternetProtocol version 4 (IPv4) Address, Internet Protocol version 6 (IPv6)Address, IPv4 Address plus Mask, IPv6 Address plus Mask, and AddressRange.

The data field 322 includes data matching the type. For example, if thetype is IPv4 Address, an acceptable value for the data field 322 is a32-bit number in range of 00.00.00.00 to 255.255.255.255 as expressed indotted decimal notation. In some instances, the type 320 provides formultiple values in the data field 322. The Address Range, IPv4 Addressplus Mask, and IPv6 Address plus mask types allow two IP address values,defining a beginning and ending range of IP addresses. For maximumflexibility, the architecture also permits user-defined types.Alternatively, additional types are manually added to the systemarchitecture.

The layer Id:field Id field 332 is used to identify an originating layerand a parameter from the originating layer, respectively. Theoriginating layer and the parameter from the originating layer definepacket parameters, i.e. layer parameters and packet context that thedata 322 is compared against. The originating layer identifies aparticular kernel or user layer. The parameter from the originatinglayer identifies a specific parameter associated with the originatinglayer. As a specific example is illustrated by filter condition 326. Thetype is IPv4 thereby indicating the data 322 is a 32-bit IP address. Thelayer Id is “IP” representing that the 32-bit number is an IP, i.e.network, layer parameter. The field Id is “Src IP Addr” which in theexample represents an IP layer parameter, specifically a source IPaddress. The IP address provided in the data filed is “123.3.2.1”indicating that any packet with that source IP address meets the filtercondition thereby matching the filter.

The action 326 designated in the filter 310 is permit, block, callout,or null. If the action 324 in the filter 310 is permit or block and thepacket matches the filter 310, the permit or block action is returned tothe requesting layer. The permit and block actions are typically used toimplement firewall policy. If the action 316 is callout, the policyengine issues its own classification request that includes the fullpacket, layer parameters, context and identification of the matchingfilter to the designated callout module 258. The callout module 258performs its programmed function on the packet, e.g. intrusiondetection. The callout may return an action (either permit, block) tothe policy engine, which in turn relays the action to the requestinglayer. The callout is also capable of maintaining packet context that islikewise returned to the requesting layer via the policy engine 256.

The kernel policy engine or user policy engine also returns a policycontext 317. The policy context 317 is used to store policy other thanfirewall policy, such as security policy or QOS policy. The policycontext is any suitable data structure. For example, the policy contextis a 64 bit number that is interpreted by a process that added thepolicy context 317. The policy context in the filter may include actualpolicy or a value that is used by the system to map to the actualpolicy.

FIG. 5 illustrates an example of a data structure 330 used for thepacket context that is maintained by the kernel and user layers, and thecallout modules 258. Each entry includes a layer Id:field Id 332 and acorresponding value 334. The layer Id:field Id 332 has the same meaningas the layer Id:field Id 324 provided as part of the filter conditions318 in the filters 310 (FIG. 4). Namely, the layer Id:field Id 322identifies the originating layer and the layer parameter from theoriginating layer for the data in the value field 334. The value field334 includes a specific layer parameter.

As a specific example, entry 336 includes the layer Id:field Id 332“NDIS: Src. MAC Addr.” “NDIS” represents a Network Driver InterfaceSpecification implementation of the link layer 274 (FIG. 1). “Src MACaddr.” represents a source MAC address. Thus, the layer:field Id 332indicates that the data in the value field 334 is a source MAC addressthat was processed by the NDIS (Link) layer. The value field 334includes the actual source MAC address, which in the example is“00.08.74.4F.22.E5” as expressed in hexadecimal notation.

As a second example, entry 338 has a layer Id:field Id 332 of “NDIS:IFNo.” This again identifies the layer as NDIS, but in this caseidentifies the parameter as “IF No” representing an interface number asthe specific NDIS parameter. The value field 334 includes the actualinterface number, which in this case is 2.

As a third example, entry 340 has a layer Id:field Id 332 of “IP:Dst IPAddr.” The “IP” represents the network layer using the IP protocol andthe “Dst IP Addr” represents a destination IP address as the IP layerparameter. The value field 334 includes the actual destination IPaddress of “123.3.2.1.”

Having described the underlying firewall architecture, attention isdrawn to the functional interfaces of the system and exemplary methodsthat are performed using the underlying firewall architecture describedherein. The functional interfaces are implemented as a plurality ofapplication programming interfaces (APIs). The APIs include the layerAPI 280, the callout API 284, the filter engine API 266, and the keyingmodule API 288 as illustratively shown in FIG. 6 and FIG. 7.

The layer API 280 facilitates data exchange between the kernel layersand the kernel policy engine 256. By extension, the methods describedfor the Layer API 280 also facilitate data exchange between the userlayers 282 and the filter module 294 and are included as part of thekeying module API 288 described below. As shown, the layer API 280includes a Classify method 350, an Add Layer method 352, and a DeleteLayer method 354.

The Classify method 350 is used by the requesting layer to send layerparameters, the packet as received by the requesting, and the packetcontext to the kernel policy engine 256 or the filter module 288. Thekernel policy engine 256 or filter module 288 compares the (1) layerparameters from the requesting layer and (2) packet context entries tothe filter conditions 318 in each filter 310 assigned to the requestinglayer to identify matching filters. The following is an exemplaryimplementation of the Classify method. It will be understood that thefollowing methods are described as receiving or returning data values.According to known programming techniques, the methods may use pointersto data values instead of actual data values. NTSTATUS WFPClassify (  IN ULONG LayerId,   IN WFP_INCOMING_VALUES* pInFixedValues,   INWFP_INCOMING_CONTEXT_VALUE* pInContext,   PVOID pPacket, OUTWFP_ACTION_TYPE* pActionType,   OUT UINT64* pOutContext );

Where the following characterizes the recited parameters.

LayerId identifies the kernel or user layer issuing the classificationrequest, i.e. the requesting layer. Referring to FIG. 3, the Layer Ididentifies the layer as the data stream layer 268, the transport layer270, the network layer 272, the link layer 274 or a user layer such asthe keying module layer. Other layers are valid if added to the system.

pInFixedValues includes a subset of the layer parameters processed bythe requesting layer. The pInFixedValues, along with the packet contextentries, are compared to the filter conditions to determine if thepacket matches the filter. The default layer parameters included in thepInFixedValues for kernel layers are identified in Table A below. Thereare no default parameters for the user layers. It will be understoodthat the following values are exemplary only as an advantage of thearchitecture is that it allows the layers to use any values accessibleto that layer. TABLE A Layer Default Layer Parameters Link Layer Sourceand Destination MAC Addresses; Interface Number Network Layer Source andDestination IP Addresses; Protocol Type; Local Address Type TransportLayer Source and Destination Port Numbers; Application Decipheredapplication layer protocol payload

pInContext includes the context data structure 330 (FIG. 5) as receivedby the requesting layer. The packet context is used in conjunction withthe layer parameters to identify matching packets.

pPacket includes the entire packet as received by the requesting layer.

pActionType includes the action 316 that is returned to the requestinglayer. The action 316 returned is permit, block, continue, or null asidentified in the matching filter, or callout modules executed by thematching filter. As previously described, the action 316 is used toimplement and identify network firewall policy.

pOutContext includes the policy context data. As previously described,the policy context is used to implement network policies associated withIPSec, QOS and any other non-firewall filter based policy.

The Add Layer 352 and Delete Layer 354 methods are used to add andremove a user or kernel layer from the management module 214,respectively. The following is an exemplary form of the Add Layer 352method.

NTSTATUS

AddExtensionLayer(OUT PULONG pLayerId);

Where in the following characterizes the recited parameter.

pLayerId is a unique layer identification value returned to the layerbeing added, i.e. the layer executing the Add Layer method.

In an embodiment of the invention, certain layers are included in thearchitecture when the operating system is initiated. Examples of suchlayers include the link, network and transport layers. Accordingly, theAddExtensionLayer method is not required to include these layers in theframework. A LayerSetProperties method is provided to identify, for thepolicy engine, which fields are valid filter conditions for the layer,how to calculate the filter weight, and the like. The following is anexemplary form of the LayerSetProperties method/ WIN32_ERR WINAPIFwpmLayerSetProperty0 ( IN FWPM_ENGINE_HANDLE engineHandle, IN constGUID* layerId, IN const FWPM_LAYER_PROPERTY0* layerProperty );

Wherein the following characterizes the recited parameters.

enginehandle is a handle to the policy engine.

layerId identifies the layer.

layerProperty identifies the layer properties including the layer fieldsand calculation of filter weight.

The following is an exemplary form of the Delete Layer 406 method.

NTSTATUS

RemoveExtensionLayer(ULONG LayerId);

LayerId identifies the layer being removed; i.e. the layer executing theDelete Layer method.

The Callout API 284 facilitates data exchange between the kernel or userpolicy engine and the callouts. Like the Layer API 280, the Callout API284 has a Classify method. The Classify method 356 of the Callout API284 is similar to the Classify method 402 of the Layer API 280 exceptthat it also includes matching filter data. The following is anexemplary form of the Classify method 356 used to execute a callout.typedef NTSTATUS (*WFP_CALLOUT_CLASSIFY_FN) (   IN constWFP_INCOMING_VALUES* fixedValues,   IN WFP_INCOMING_CONTEXT_VALUE*wfpContext,   IN VOID* packet,   IN WFP_FILTER* matchedFilter,   OUTWFP_ACTION_TYPE* action,   OUT UINT64* outContext );

Wherein the following characterizes the recited parameters.

fixedValues includes the layer parameters sent from the requestinglayer. The fixedValues is the same data provided by the requesting layerin pInFixedValues data sent as part of the Classify method 350 in thelayer API 280.

wfpContext includes the context data structure 330 (FIG. 5). This datais the same as sent by the requesting layer in the pInContext sent aspart of the Classify method 350 in the layer API 280.

packet includes the entire packet as received by the requesting layer.This data is the same as sent by the requesting layer in the pPacketsent as part of the Classify method 350 in the layer API 280.

matchedFilter identifies the filter requesting the callout. Typically,the matching filter is identified by the filter Id 312 of the matchingfilter 310 initiating the Classify method 350 of the callout API 284.

pActionType includes the action that is returned to the kernel or userpolicy engine from the callout 258. If the pActionType is Permit orBlock, it is returned to the requesting layer as the pActionTypereturned by the Layer API 280. The callout can also return a Continueaction that instructs the policy engine to continue applying matchingfilters to the packet.

pOutContext includes the policy context data, such as security or QOSpolicy data.

The callout API 408 also includes the Notify method 358. The Notifymethod 358 is used to notify a callout when a filter 310 is added to theset of installed filters 282 that identifies as one of its Actions 316,the callout module 258. The Notify provides the callout with anopportunity to take any required action such as allocating orde-allocating buffers that will be used by the callout 258 when it isexecuted by the policy engine 256. The following is an exemplary form ofthe Notify method 358. typedef NTSTATUS (*WFP_CALLOUT_NOTIFY_FN) (   INWFP_NOTIFY_ENUM notify,   IN WFP_FILTER* filter );

Wherein the following characterizes the recited parameters.

notify includes a numerical value that indicates whether the filter isbeing added or deleted. For example, a value of 1 indicates the filteris being added and a value of 2 indicates that the filter is beingdeleted.

filter identifies the filter being added or deleted by unique value.This may be accomplished by providing the Filter Id 312 included as partof the filter 310. The callout API also includes a Callout Registrationmethod 360 and Callout Deregistration 362 method to add and removecallout modules, respectively. An exemplary form the CalloutRegistration method 360 is as follows: NTSTATUS WfpRegisterCallout (  IN const GUID* calloutId,   IN const WFP_CALLOUT* callout,   IN constSECURITY_DESCRIPTOR* sd );

Wherein the following characterizes the recited parameters.

callout Id provides a unique identification for the registering calloutmodule.

callout provides any callout specific information such as a driverservice name, device name, and pointers to the callout classify andnotify functions.

sd provides a security descriptor for the callout. The securitydescriptor identifies which processes can and read and delete thecallout.

An exemplary form of the Callout Deregistration method 362 is asfollows: NTSTATUS WfpDeregisterCallout (   IN const GUID* calloutId );

Wherein the following characterizes the recited parameter.

callout Id is the unique Id of the callout to be removed.

The filter engine API 266 facilitates data exchange between the userpolicy engine 260 and the kernel policy 256 engine. As shown, the filterengine API 266 includes an Add Filter method 364, a Delete Filter method366, and an Enum Layer method 368.

The Add Filter 364 and Delete Filter 366 methods are used to add a newfilter to the set of installed filters 282 and to delete an existingfilter from the set of installed filters 282, respectively. Thefollowing is an exemplary form of the Add Filter method 364. NTSTATUSAddFilterToLayer (   ULONG LayerId,   WFP_FILTER* pFilter );

Wherein the following characterizes the recited parameters.

LayerId identifies the layer assigned to the filter.

pFilter is the filter 310 being added to the set of installed filters282.

The following is an exemplary form of the Delete Filter method 366.NTSTATUS DeleteFilterFromLayer (   ULONG   LayerId,   ULONG   FilterId);

Wherein the following characterizes the recited parameters.

LayerId identifies the layer that the filter is assigned to.

pFilter is the filter being deleted from the set of installed filters.

The Enum Layer method 368 provides a mechanism for the user policyengine 260 to identify all filters matching a set of criteria. Thisallows the management API to identify conflicting filters for filterarbitration and conflict resolution. The following is an exemplary formof the Enum Layer method 368. IndexStartEnum (   PWFP_ENUM_TEMPLATEpEnumTemplate,   OUT PULONG pMatchCount,   OUT PWFP_ENUM_HANDLEpEnumHandle )

Wherein the following characterizes the recited parameters.

pEnumTemplate includes a data structure defining the filters to bereturned. For example, it include parameters that the filter conditionsmust match for the filter to be returned.

pMatchCount includes the number of filter matches based on the specifiedpEnumTemplate.

pEnumHanlde includes a reference to the matched filter entries.

The keying module API 288 provides an interface between user mode keyingmodule layers 282 and the user policy engine 260. The keying module API288 includes an IPSec SA Acquire method 370, an Expire Notify method372, and an IPSec SA Acquire Complete method 374, a Keying ModuleRegister method 376, a Keying Module Deregister method 378, an IPSecInbound Get SPI method 380, an Add Inbound SA method 382, an AddOutbound SA method 384, an Inbound SA Expire 386 method, and a KeyingModule Initiate method 388. The keying module API 288 may also includethe methods previously described for the layer API.

The keying module API is used to facilitate use of known securityprotocols, such as defined by IPSec, used by an initiating computer,user, or service and a responding computer, user, or service. IPSecincludes protocols such as AH and ESP. The ESP protocol is anauthenticating and encrypting protocol that uses cryptographicmechanisms to provide integrity, source authentication, andconfidentiality of data. The AH protocol is an authentication protocolthat uses a hash signature in the packet header to validate theintegrity of the packet data and authenticity of the sender.

The IKE protocol provides a method for an initiating computer and aresponding computer to negotiate security settings used with the AH andESP protocols. The negotiated security settings form a data structurecalled a security association (SA). The SA defines parameters such as anauthentication algorithm, encryption algorithm, keys, and the lifetimeof keys, used by ESP or AH to protect the contents of an IP packet.Because ESP and AH require an SA, an exemplary method is to use an IKEnegotiation before the ESP or AH protocols are used by the initiatingand responding computer. Alternatively, the SA can be manually created.A given SA is identified by a value known as a Security Parameter Index(SPI).

Each of the initiating and responding computers include an IPSec driverand classification module that determine, based on an IPSec policy,whether data sent between the initiating and responding computersrequires encryption or authentication. The IPSec policy is a set offilters that defines how the network device uses IPSec and includesfilter lists, authentication methods, and other information. In anembodiment of the invention, the IPSec policy is defined by filtersincluded in the set of installed filters in the kernel policy engine orthe filter module 294. The policy that applies to a packet is identifiedby invoking the keying module layer which uses the Classify method toidentify matching filters.

The IPSec SA Acquire method 370 is called by the user policy engine 260(via a client proxy) to pass a driver acquire or an external initiaterequest to the keying module layer. The keying module layer returns thiscall and does the negotiation asynchronously. Once the keying modulelayer has completed the negotiation, the keying module layer calls theIPSec SA Acquire Complete method 374 to notify the user policy enginethat the negotiation is complete. The following is an exemplary form ofthe IPSec SA Acquire method. typedef WIN32_ERR(*PROCESS_IPSEC_SA_ACQUIRE- 0) (   IN FWP_IPSEC_ACQUIRE_CONTEXT0ipsecContext,   IN const FWP_IPSEC_SA_ACQUIRE0* acquire,   INFWP_IPSEC_SPI inboundSAspi );

Wherein the following characterizes the recited parameters.

ipsecContext is a handle to link the acquire with the SA being added.

acquire includes the necessary information for negotiating the SAaccording to known protocols such as IKE.

inboundSAspi includes a SPI that is used for an inbound SA.

The Expire Notify method 372 is called to pass an expire-notify to thekeying module layer that added the inbound SA. The following is anexemplary form the Expire Notify method. typedef VOID(*PROCESS_IPSEC_SA_EXPIRE0) (   IN const FWP_IPSEC_SA_EXPIRE_NOTIFY0*expireNotify );

Wherein the following characterizes the recited parameters.

expireNotify contains information identifying the expiring SA. Forexample, in the case of an outbound SA, the SPI is provided.

The IPSec SA Acquire Complete 374 method is called by a keying modulelayer to close the user policy engine's context after it has finishednegotiation and added all the SAs, or after it has come across an error.After this method is executed, the keying module layer does not reusethe ipsecContext for any other API method. The following is an exemplaryform the IPSec SA Acquire Complete method. WIN32_ERRFwpIPSecSAAcquireComplete0 (  IN FWPM_ENGINE_HANDLE engineHandle,  INFWP_IPSEC_ACQUIRE_CONTEXT0 ipsecContext,  IN constFWP_IPSEC_NEGOTIATION_STATUS0* status );

Wherein the following characterizes the recited parameters.

engineHandle provides a handle to the user policy engine 260.

ipsecContext is the context passed by user policy engine with the IPSecAcquire method.

status provides status and other details of the SA negotiation. Thestatus is returned by the user policy engine 260 if the acquire wasexternally initiated via FwpKeyingModuleInitiate0.

The Keying Module Register method 376 is called by a keying module layerto register with the user policy engine 260 and pass its functionpointers. The following is an exemplary form of the Keying ModuleRegister method. WIN32_ERR FwpKeyingModuleRegister0 (   INFWPM_ENGINE_HANDLE engineHandle,   IN const GUID* keyingModuleID,   INconst FWP_KEYING_MODULE_INFO0* keymodInfo );

Wherein the following characterizes the recited parameters.

engineHandle provides the handle to the user firewall engine 260.

keyingModuleID is a unique ID for the keying module layer.

keymodInfo includes registration information about the keying modulelayer such as pointers to process IPSec SA Acquire and process IPSec SAExpire functions.

The Keying Module Deregister method 378 is called by the keying modulelayer to deregister the keying module from the user policy engine 260.The following is an exemplary form of the Keying Module Deregistermethod. WIN32_ERR FwpKeyingModuleDeregister0 (   IN FWPM_ENGINE_HANDLEengineHandle,   IN const GUID* keyingModuleID );

Wherein the following characterizes the recited parameters:

enginehandle is the handle to the user policy engine 260.

keyingModuleID is the unique ID of the keying module layer.

The IPSec Inbound Get SPI method 380 is called by the keying modulelayer to obtain the SPI for a new inbound. SA. The IPSec Inbound Get SPImethod 380 is usually used when the keying module layer executes in aresponding network device. The following is an exemplary form the IPSecInbound Get SPI method. WIN32_ERR FwpIPSecSAInboundGetSpi0 (   INFWPM_ENGINE_HANDLE engineHandle,   IN const FWP_IPSEC_TRAFFIC0*ipsecTrafficDescription,   IN const FWP_IPSEC_UDP_ENCAP0* udpEncapInfo,  OUT FWP_IPSEC_SPI* inboundSpi );

Wherein the following characterizes the recited parameters.

engineHandle is the handle to the user firewall engine 260.

ipsecTrafficDescription is a 5-tuple description for creating an inboundlarval SA. The 5-tuple includes source and destination IP addresses,source and destination ports, and transport layer protocol type.

udpEncapInfo is UDP encapsulation data for creating the larval SA. UDPencapsulation is a known method of embedding a packet formattedaccording to a security protocol into an unencrypted UDP packet.

inboundSpi is the SPI for the inbound SA.

The Add Inbound SA method 382 is called by the keying module layer toadd an inbound SA, i.e. update the larval SA. The user policy engine 260uses the SPI in the SA to map this call to its internal state, and ioctlthe SA down to the IPSec driver. The following is an exemplary form ofthe Add Inbound SA method. WIN32_ERR FwpIPSecSAInboundAdd0 (   INFWPM_ENGINE_HANDLE engineHandle,   IN const FWP_IPSEC_SA_STRUCT0*inboundSA );

Wherein the following characterizes the recited parameters.

engineHandle in the handle to the user policy engine.

inboundSA includes the inbound SA.

The Add Outbound SA 384 method is called by a keying module layer to addan outbound SA. The user policy engine uses an inbound SPI parameter tomap this call to its internal state, and ioctl the SA down to the IPSecdriver. The following is an exemplary form the Add Outbound SA method:WIN32_ERR FwpIPSecSAOutboundAdd0 (   IN FWPM_ENGINE_HANDLE engineHandle,  IN FWP_IPSEC_SPI inboundSpi,   IN const FWP_IPSEC_SA_STRUCT0*outboundSA );

Wherein the following characterizes the recited parameters.

engineHandle is the handle to the user firewall engine 260.

onboundSpi is the SPI for the inbound SA, with which an outbound SA ispaired.

outboundSA includes the outbound SA.

The Inbound SA Expire method 386 is called by the keying module layer toexpire the inbound SA that was previously added. The following is anexemplary form the Inbound SA Expire method 386. WIN32_ERRFwpIPSecSAInboundExpire0 (   IN FWPM_ENGINE_HANDLE engineHandle,   INconst FWP_IPSEC_SA_EXPIRE0* expire );

Wherein the following characterizes the recited parameters. enginehandleis the handle to the user firewall engine 260.

expire includes data for the SA to be expired.

The Keying Module Initiate method 388 is called by known externalapplication like RAS, Winsock API, and the like to initiate the keyingmodule layer and setup SAs before an application starts sending itsnetwork traffic. The user policy engine 260 asynchronously pends the RPCcall, gets the SPI from an IPSec driver, and passes the acquire to theappropriate keying module. Once the keying module layer callsFwpIPSecSAAcquireComplete0, the user firewall engine completes theasynchronous RPC with the negotiation status. The following is anexemplary form of the Keying Module Initiate method. WIN32_ERRFwpKeyingModuleInitiate0 (  IN FWPM_ENGINE_HANDLE engineHandle,  INconst FWP_IPSEC_SA_ACQUIRE0* acquire,  IN HANDLE waitEvent,  OUTFWP_IPSEC_NEGOTIATION_STATUS0* negotiationStatus );

Wherein the following characterizes the recited parameters.

engineHandle is the handle to the user policy engine 260.

acquire includes data necessary for negotiating an SA.

waitEvent is a handle to an event that is triggered when negotiationstatus is available. If a client, i.e. calling external application, isnot interested in waiting for the negotiation to complete, it can setthis parameter to NULL. Internally the client proxy optionally passesthis event to RPC and request it to set the event once the asynchronousRPC call completes.

negotiationStatus includes an outcome of the negotiation. ThenegotiationStatus is NULL if waitEvent is NULL. OtherwisenegotiationStatus remains valid until the waitEvent is triggered.

FIG. 8 illustrates the methods used to find matching filters for apacket and return the action and/or policy context to a requestinglayer. As shown, a first requesting layer 404 obtains network policy byissuing a request 408 to the policy engine 400. The policy engine 400 isthe kernel policy engine 256 or the user policy engine 260 with filtermodule 294. The policy engine 400 includes installed filters 402defining a plurality of network policies, for example security, QOS, andfirewall policy.

The first requesting layer 404 may be a user mode layer 282, such as thekeying module layer, or a kernel layer 254, such as one of the layers inthe network stack. The first requesting layer 404 communicates with thepolicy engine 400 via the layer API.

The request 408, e.g., a classification request using the Classifymethod, includes the layer parameters 410, the packet context 412, andthe full packet 414 as received by the requesting layer 404. The policyengine 400 uses the layer parameters 410 and the packet context 412 toidentify any matching filters from the installed filters 402. Typically,the policy engine 400 applies filters in order of the weight specifiedby the matching filters. The policy engine 400 then returns values 416including an action 418 and the policy context 420. The action 418 isused to return firewall policy such as permit or block. The policycontext 420 is used to return other policy such as security or QOSpolicy. The returned action 418 and policy context 420 are indicated asnone or null where the filter does not include corresponding policy.

The first requesting layer 404 may interact with a second requestinglayer 406. This occurs when the requesting layer is a kernel layer 254in the network stack. The first requesting layer 404 may update thepacket context 422 with the layer parameters processed by the requestinglayer. The first requesting layer 404 also may process the packetaccording to a layer protocol. The requesting layer passes the modifiedpacket context 422 to the second requesting layer 406. The requestinglayer also passes the packet 424, after it is processed according to thelayer protocol. For example, if the first requesting layer 404implements the IP protocol, it processes the packet according to the IPprotocol. The first requesting layer then passes the packet to thesecond requesting layer 406, which in the case of an inbound packet is atransport protocol layer and in the case of an outbound packet is a linklayer. The second requesting layer 406 may then repeat the process bysending a classification request and receiving returned action andpolicy context values.

FIG. 9 illustrates a method, labeled 500, used by the requesting layerto obtain applicable network policy, e.g., action and policy context,for a packet. In step 502, the requesting layer receives the full packetand corresponding packet context from a previous layer or anotherprocess or program module

In step 504 the requesting layer identifies the layer parameters. Thelayer parameters are the parameters to be used, in combination withpacket context, to identify matching filters. The default layerparameters are described above in Table A and are included in thepInFixedValues of the Classify method 350.

In step 506, the requesting layer issues the classification request tothe kernel or user policy engine. An exemplary method of issuingclassification requests was described with the reference to the Classifymethod 350 in the layer API 280.

In response to the classification request, an action and policy contextis returned to the requesting layer as shown in step 508. The requestinglayer determines, based on the returned action, whether to drop thepacket 508. If the policy engine returns block as the action then therequesting layer drops the packet. The requesting layer may also dropthe packet if the policy engine returns the action as no matchingfilters found. As previously described, the action is used to implementfirewall policy. If the matching filters do not include firewall policy,the returned action may be none or null.

Steps 510, 512, 514 are normally only carried out when the requestinglayer is a layer in the network stack, but are optionally carried out byuser mode layers. If the returned action is permit, further packetprocessing occurs. In step 510, the requesting layer modifies the packetcontext to include layer information, typically the same type ofinformation that was included as the layer parameters in theclassification request. Thus, Table A (above) not only identifies thelayer parameters but also the default information added by each layer tothe packet context. The packet context is maintained in a data structuresuch as the data structure described with reference to FIG. 5.

In step 512, the requesting layer processes the packet according to theprotocol implementation for that layer. Such processing is well knownand need not be described in detail herein. Exemplary protocolimplementations include HTTP, FTP, SMTP, and RPC for the applicationlayer, TCP and UDP for the transport layer, IP for the network layer,and NDIS for the link layer.

In step 514, the requesting layer passes the packet, processed accordingto the layer protocol, along with the modified packet context to a nextlayer. The process 500 is repeated by each layer and continues until thepacket traverses all layers in a series of layers, e.g., the layers inthe network stack, or until the packet is dropped by one of the layers.

Referring to FIG. 10, a method 520 used by the kernel or user policyengine to identify matching filters and return the action and policycontext to the requesting layer will now be described. In step 522, thepolicy engine receives the packet, layer parameters, and packet contextfrom the requesting layer via the appropriate API.

In step 524, the policy engine identifies one or more matching filters.In an embodiment of the invention, filters are assigned to a particularrequesting layer. The policy engine only attempts to identify filters asmatching if the filter is assigned to the requesting layer and thepacket parameters match all filter conditions 318 (FIG. 5). Aspreviously described the packet parameters include both layer parametersfrom the requesting layers and the packet context. After all matchingfilters are identified, the policy engine orders the filters based onthe weight field 314 in each matching filter. Alternatively, filters arenot assigned to a particular requesting layer and all filters may be amatching filter.

In step 526, the policy engine applies the filter with the highestweight field 314 that has not yet been applied. Specifically, the policyengine identifies the action 316 specified in the filter and the policycontext. If the action 316 designates a callout module, the policyengine 256 executes the callout. The callout may return an Action to thepolicy engine.

If the action was not callout, or after the callout is executed, thepolicy engine returns an associated action and policy context from thematching filter or as identified by the callout, to the requesting layeras shown in step 536. Alternatively, the policy engine waits to executestep 536, i.e. return the action, until all matching filters have beenapplied.

In step 534, the policy engine determines if any additional matchingfilters exist. If not, the process terminates. If additional matchingfilters do exist, the process returns to step 526 where the next highestpriority filter is applied. The process continues until all matchingfilters are applied. Alternatively, the process terminates once aterminating action is identified for the packet. An action type may bedefined as a terminating action. By default, permit and block areterminating actions. If no matching filters are identified for thepacket, the policy engine notifies the requesting layer that no matchingfilters were found.

FIG. 11 illustrates the process 540 used by the user policy engine 260to add new filters into the set of installed filters. The filters may beinstalled into the kernel policy engine 256 or into the filter module294. In step 542, the user policy engine receives policy from one of thepolicy providers 262. The policy providers include known processes suchas LIPS, GUIs, and the like. If necessary, the user policy engine placesthe policy in filter form by defining the policy in terms of filterconditions, an action, and policy context.

In step 544, the filter is assigned a weight value by the user policyengine. The weight value is assigned by the policy provider, e.g.manually by a user via the policy provider GUI. Alternatively, the userpolicy engine automatically calculates the weight value. The kernelpolicy engine 256 uses any suitable method to calculate weight. Forexample, filters with more specific filter conditions are given higherweight values than less specific filters. More specific filters havefilter conditions that match a smaller number of potential packets. Forexample, a filter that includes a single IP address as its filterconditions is more specific than a filter that includes a range of IPaddresses as its filter conditions.

In step 548, the user policy engine 260 compares the new filter to eachof the installed filters assigned to the same layer to identify anyconflicts. To conflict the filters must share a common set of filterconditions such that they will act on the same packet and identifydifferent actions. For example, if the filter condition for theinstalled filter is a source IP address in the range of 123.4.0.0 to123.4.0.100 with an associated action of permit and the new filter hasfilter condition with source IP addresses in the range 123.4.0.50 to123.4.0150, with an associated action of block, the new and installedfilter overlap to the extent both filter conditions include the IPaddress range 123.4.0.50 to 123.4.0.100.

If the filters conflict, the user policy engine 260 resolves theconflicting using any suitable technique as shown in step 552. A methodfor calculation of filter weight and identifying and resolving filterconflicts is described in copending U.S. patent application Ser. No.10/456,433 entitled “Method for Managing Network Filter Based Policy”.The new filter may be added to the set of installed filters as part ofthe conflict resolution process. If the new filter does not conflictwith the set of installed filters, the new filter is added into the setof installed filters, either in the user policy engine or the kernelpolicy engine as shown in step 550.

If the new filter is loaded into the set of installed filters, anycallouts that are executed by the filter, i.e. the callouts are includedas an associated action in the filter are notified as shown in step 554.An exemplary method of notifying the callout was described withreference to the Notify method 412 described as part of the callout API284 (FIG. 6).

All of the references cited herein, including are hereby incorporated intheir entireties by reference.

In view of the many possible embodiments to which the principles of thisinvention may be applied, it should be recognized that the embodimentdescribed herein with respect to the drawing figures is meant to beillustrative only and should not be taken as limiting the scope ofinvention. For example, those of skill in the art will recognize thatthe elements of the illustrated embodiment shown in software may beimplemented in hardware and vice versa or that the illustratedembodiment can be modified in arrangement and detail without departingfrom the spirit of the invention. The present invention can be used tomanage and execute filters and filter based polices of these andadditional processes. Therefore, the invention as described hereincontemplates all such embodiments as may come within the scope of thefollowing claims and equivalents thereof.

1. A framework for integrating a plurality of filter based policies tobe applied to packets of data including at least a firewall policy and asecurity policy, comprising: a set of layer processes for identifying atleast one parameter associated with a packet; a policy engine incommunication with the set of layer processes; and a set of filtersstored in the policy engine, each filter in the set of filters havingfilter conditions, an action identifying the firewall policy, and apolicy context identifying the security policy.
 2. The framework ofclaim 1, wherein the plurality of filter based policies further includea quality of service policy that identifies communication settings to beapplied to packets, the quality of service policy being defined by thepolicy context in the set of filters.
 3. The framework of claim 1,further comprising: a requesting layer process in the set of layerprocesses that sends the at least one parameter to the policy engine andthe policy engine identifies a matching filter from the set of filtershaving filter conditions that match the at least one parameter and thepolicy engine returns the firewall policy and the security policy to therequesting layer.
 4. The framework of claim 3, wherein the requestinglayer is a keying module layer and the security policy in the matchingfilter identifies a policy for negotiating a security associationaccording to a key negotiation protocol.
 5. The framework of claim 4,wherein the at least one parameter is a plurality of parameters and theplurality of parameters comprise source and destination IP addresses,source and destination ports, and a protocol type.
 6. The framework ofclaim 4 wherein the key negotiation protocol is an IKE protocol.
 7. Theframework of claim 3, wherein the requesting layer further sends packetcontext and the policy engine further identifies the matching filterfrom the packet context.
 8. A computer-readable medium for executingcomputer-executable instructions for facilitating a framework forintegrating a plurality of filter based policies to be applied topackets of data including at least a firewall policy and a securitypolicy, comprising: a set of layer processes for identifying at leastone parameter associated with a packet; a policy engine in communicationwith the set of layer processes; and a set of filters stored in thepolicy engine, each filter in the set of filters having filterconditions, an action identifying the firewall policy, and a policycontext identifying the security policy.
 9. The computer readable mediumof claim 8, wherein the plurality of filter based policies furtherinclude a quality of service policy that identifies communicationsettings to be applied to packets, the quality of service policy beingdefined by the policy context in the set of filters.
 10. The computerreadable medium of claim 8, further comprising: a requesting layerprocess in the set of layer processes that sends the at least oneparameter to the policy engine and the policy engine identifies amatching filter from the set of filters having filter conditions thatmatch the at least one parameter and the policy engine returns thefirewall policy and the security policy to the requesting layer.
 11. Thecomputer readable medium of claim 10, wherein the requesting layer is akeying module layer and the security policy in the matching filteridentifies a policy for negotiating a security association according toa key negotiation protocol.